Skip to main content

Nine Reasons I LOVE writing tests and Test-driven Development

· 3 min read
Lars Opitz
Lars Opitz
Passionate Software Craftsperson | Seasoned Agile Leader @ eBay
  1. A test is the first consumer of my production code I have used too many frameworks, libraries, etc. which make working with them hard or nearly impossible. Guilty myself 😉 Creating the first consumer alongside with the production code helps me to improve the usability of my solutions.

➡️ TDD is consumer-driven development ⬅️

  1. First the test, then the production code With the test already written, I can immediately verify my production code that I’m so proud of—or improve until it's correct.

  2. Working in small increments A test, a little prod code, a test, a little prod code, maybe a little refactoring - slicing the complexity of a problem into small/very small pieces helps me keep the overview, stopping when I’m done and not missing requirements.

  3. Clear on problem space and language Code is a means of communication. We tell the machine what to do, and also communicate with other developers, including our future self. Writing a test makes me use the language of the problem space as I formally describe the (sub-)requirement. By the tiny iterations, I automatically continue to use this language in the prod code. This makes it easier to come up with better naming.

  4. The Kick Whenever my test switches from red to green, especially if it was a harder nut to crack, there is this tiny rush of excitement. Be careful though, it can be addictive. 😏

  5. Better testable By writing the test first and implementing only as much logic as needed to fulfill the test, it is nearly impossible to make the production code not testable.

  6. Better Design Making the production code easy to test is reached by using the same patterns that good software design is characterized by. Pretty fast you will discover what patterns help and what patterns impede.

  7. Psychological safety aka high coverage for the right reasons “Reach the test coverage goal or else!” If test coverage goals are defined, devs will find ways to satisfy these. A creative way to increase the coverage is not having assertions in the test cases.

I call these tests ☣ hazardous tests ☣ as they give developers a wrong feeling of safety. They would only realize they broke something until it’s too late and the customer is impacted.

We should strive for a high coverage for ourselves, to have a proper safety net in place to change critical systems easily and without any fear.

  1. Tests as executable documentation Tests document what the system can do and show how the system’s functionality is triggered. This kind of documentation will not diverge from the actual implementation.

Writing tests first makes them a first-class citizen in the development process. Systems created using TDD have a higher quality and lower maintenance costs for all the reasons above.

Do you love writing tests like I do? Do you GenAI for test generation and how does it work for you with TDD?

Let's discuss!​

Please let's discuss on LinkedIn.